-
Notifications
You must be signed in to change notification settings - Fork 147
Make delays depending on available processors #2013
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make delays depending on available processors #2013
Conversation
Currently we use a fixed delay for a given job priority, depending on the number of jobs running and other factors this can considerably delay some actions and make eclipse feel laggy. This now makes these values dependent on the number of CPUs installed in the machine, as we can assume more CPUs can do the work better in parallel without additional sleep delays.
Test Results 1 920 files - 27 1 920 suites - 27 1h 25m 36s ⏱️ - 18m 42s For more details on these errors, see this check. Results for commit a27a195. ± Comparison against base commit 77879f3. |
|
I've run JDT and JDT debug tests with this change, looks fine. In general this change makes sense, with high number of cores there is no need to wait a second for decoration thread to start, there is almost always a core free. Original code was written more than 20 years ago, highly likely on a single or dual core PC, therefore it was valid to delay "unimportant" jobs. Now on my workstation with 32 cores it is a completely different picture, delaying only wastes my time. |
|
I tend to merge this PR now and trigger an IBuild to see whether any unexpected side effects will appear due the timing change. Any objections? |
|
Alright then go a haed and trigger a build. |
|
I'm considering whether it maybe makes sense to update the Platform's SimRel M1 contribution before tomorrow's deadline? What's your opinion? How serious/noticeable is this problem generally? |
For me it was a deal breaker. So if the tests would not show any issues, why not? |
|
Yes, that was my sense/guess. I think the only potential drawback is that RAP's contribution might introduce duplicates, but I don't think those duplicates are harmful. Would it be problematic to contribute a new version of the Platform to SimRel later today? When do you actually finalize the RAP contribution? |
|
I todays I-Build I see a lot of errors during startup of an RCP if I do not clean-up the project before running. Stuff like: java.lang.Error: Unresolved compilation problems: If I run "Project -> Clean" the the project is fine again, auto-build is active. What I do to see the errors: 1.) Start RCP app Not sure if this is related to this change but it seems to be a good candidate, so if someone else is seeing this.... |

Currently we use a fixed delay for a given job priority, depending on the number of jobs running and other factors this can considerably delay some actions and make eclipse feel laggy.
This now makes these values dependent on the number of CPUs installed in the machine, as we can assume more CPUs can do the work better in parallel without additional sleep delays.
FYI @iloveeclipse @merks @vogella
I'll keep this PR open for a few days in case someone likes to review this, but the change seem save enough as I tried to even reduce the delay always to zero and didn't see any negative effects here. In many cases (e.g. no builds or other jobs running) this is even zero in some cases as the value is multiplied with the number of running jobs. In other cases it seems even unused or only used for rescheduling purpose.